comment
authorJoey Hess <joeyh@joeyh.name>
Tue, 20 Sep 2022 16:56:16 +0000 (12:56 -0400)
committerJoey Hess <joeyh@joeyh.name>
Tue, 20 Sep 2022 16:56:16 +0000 (12:56 -0400)
doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_6_4d05a896fd57b55388fb21638ed02233._comment [new file with mode: 0644]

diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_6_4d05a896fd57b55388fb21638ed02233._comment b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_6_4d05a896fd57b55388fb21638ed02233._comment
new file mode 100644 (file)
index 0000000..848f170
--- /dev/null
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-09-20T16:42:18Z"
+ content="""
+Ah, here's the smoking gun: In Remote.Helper.ExportImport,
+it gets the cids for a key. And promptly picks the first one to pass to
+retrieveExportWithContentIdentifier, ignoring all the rest.
+It also gets the first recorded export location and likewise passes it to
+retrieveExportWithContentIdentifier.
+
+It seems like a fix would be to try retrieveExportWithContentIdentifier
+with each combination of cid and export location. But that would cause an
+`O(N^2)` explosion and it's possible a remote has say 1000 empty files in
+it.
+
+Maybe instead make retrieveExportWithContentIdentifier take a list of valid
+cids, and accept any one of them? Then it would only need to be tried on
+each export location in turn until one succeeds. 
+
+(Hm, removeExportWithContentIdentifier and 
+checkPresentExportWithContentIdentifier already use a list, so similar problems
+are avoided with them.)
+"""]]